home *** CD-ROM | disk | FTP | other *** search
/ Games of Daze / Infomagic - Games of Daze (Summer 1995) (Disc 1 of 2).iso / x2ftp / msdos / biz / gd_guide / gd_guide.txt < prev   
Encoding:
Text File  |  1994-10-02  |  9.3 KB  |  215 lines

  1.  
  2.                          Game Developer
  3.                          Writers Guidelines
  4.  
  5.  Game Developer is a technical magazine devoted to the development of 
  6.  computer games.  Its audience is programmers. Game Developer will also be 
  7.  of interest to entrepreneurs in the game market and computer artists, 
  8.  but its main audience is programmers.  Good programmers.  Really, 
  9.  really good programmers.  Our editorial goal is to produce the most 
  10.  intensely useful programming magazine ever.
  11.  
  12.  We aren't interested in introductory articles.  We aren't interested 
  13.  in articles about Windows common dialog boxes. We aren't interested in 
  14.  articles about software engineering.  We're interested in highly 
  15.  technical articles about game programming.  Period.
  16.  
  17. Interviews
  18.  
  19.  Game Developer often interviews leading figures in the field of 
  20.  digital entertainment, but these are generally done by our staff.  
  21.  Just about the only time we'd be interested in a submitted interview 
  22.  would be if you had some credentials as an interviewer (a journalism 
  23.  background, for example) or if you had exceptional access to someone 
  24.  whose work is important to game development.  Even then, we'd want you 
  25.  to clear the interview with us beforehand so we could let you know 
  26.  specific questions we'd like answered.
  27.  
  28. Business Articles
  29.  
  30.  Game Developer devotes some amount of space to business issues, 
  31.  especially channel, legal, and marketing issues. Articles of interest 
  32.  here could deal with, for instance, breaking into the channel, legal 
  33.  protection when working with a distribution house, and marketing on 
  34.  the cheap.
  35.  
  36.  Of much more interest to us are articles on industry trends based on 
  37.  real numbers.  For instance, how fast is the Windows game market 
  38.  growing?  What's the market share of sport games vs. fighting games 
  39.  vs. flight simulators?  What are the sound and video chip sets that 
  40.  are gaining market share?  Such articles are of great interest to us.
  41.  
  42. Technical Articles
  43.  
  44.  Interviews and business are all well and good, but the meat of Game 
  45.  Developer is its technical articles.  Game Developer technical 
  46.  articles deal with high-performance programming in a highly 
  47.  constrained hardware environment.  They do not deal with business 
  48.  issues.  They do not deal with maintenance issues.  They do not deal 
  49.  with academic issues.  They deal with getting the job done without 
  50.  flickering, popping, jumping, or crashing.
  51.  
  52.  If you have a complex technical topic, and you're looking for guidance 
  53.  on what exactly to write, do this:
  54.  
  55.  Write a 5,000-word introductory article on the subject. Write a second 
  56.  3,000-word article that's much more in-depth and assumes all the 
  57.  introductory stuff is well understood.  Take all the terms in the 
  58.  introductory article and create a glossary of no more than one page.  
  59.  Submit the second article with the glossary as a sidebar.  Sell the 
  60.  introductory article to someone else.
  61.  
  62.  For example, multitasking.  Let's take a look at some introductory 
  63.  paragraphs and our reaction to them.
  64.  
  65.  "You want to program a flight simulator with a cinematic plot.  Your 
  66.  user will take the personality of Billy Zoom, Skateboard Punk, who 
  67.  breaks into Area 51, steals a Manta hypersonic jet and flies across 
  68.  the world battling the forces arrayed against you by the Super Secret 
  69.  NSA.  You're halfway through the program when you realize there's 
  70.  something terribly wrong.  You move, and the opposing planes move, 
  71.  making for terrible jitter.  You need multitasking!  Multitasking is a 
  72.  complex issue that can only be touched on in a magazine article.  This 
  73.  article will give an overview of the general theory of multitasking.  
  74.  So that we won't get bogged down in details, my examples will be in 
  75.  pseudocode."
  76.  
  77.  Destination: garbage can.  The tone is condescending, the focus 
  78.  elementary, and it contains the two evil words "overview," and 
  79.  "pseudocode."
  80.  
  81. What's next on the pile?
  82.  
  83.  "Abstract:  An analysis of balking protocols in high-transaction 
  84.  multitasking environments shows an unfortunate degradation in 
  85.  performance under certain circumstances.  This paper reviews existing 
  86.  balking protocols and demonstrates their theoretical weaknesses in 
  87.  these circumstances.  A new balking protocol, based on the mass of the 
  88.  Top quark, is proposed."
  89.  
  90.  Our reaction: What do we look like, a Ph.D. review board?  If you want 
  91.  to write something in the passive voice or that begins with the word 
  92.  "Abstract," we'll be happy to read it in an ACM or IEEE journal.  But 
  93.  we won't publish it in Game Developer.
  94.  
  95.  Let's try a final one:
  96.  
  97.  "Minimizing input lag, so the game reacts instantaneously to keyboard, 
  98.  joystick, or mouse data, requires something more than a naive 'get 
  99.  input, process input, display output,' loop.  I've written a series of 
  100.  efficient C++ classes that allow multiple input devices to be active 
  101.  simultaneously, eliminates type ahead problems, and require only 5K of 
  102.  overhead. This article explains the classes, how to use them, and 
  103.  suggests areas where they could be improved."
  104.  
  105.  Hello!  We'll continue reading this article.  It talks about a real 
  106.  issue for game developers, it talks about efficiency, and it has real 
  107.  code.  There's still a long way to go before we accept the article -- 
  108.  the writing's got to be coherent, the code's got to be worthwhile, and 
  109.  there has to be enough text to "wrap around the code" (at least a 10:1 
  110.  ratio of words to lines of code!).  But we're going to work with the 
  111.  author to make this article happen.
  112.  
  113.  C++, Pascal, C, and assembly language are the most important languages 
  114.  for Game Developer.  It does not mean we are exclusive to them, 
  115.  though, or that we have any concrete ratio of C++ to Pascal to ASM 
  116.  that we stick to.
  117.  
  118. Implementation Details
  119.  
  120.  We know that you'd like to get a quick response to your article, but 
  121.  the simple fact is that we deal with things in a strict FIFO manner.  
  122.  When an article comes in, it goes to the bottom of the pile without a 
  123.  glance.  Sorry.  Because we print out the articles, put them in a 
  124.  stack, and read them, we've discovered that when an article is 
  125.  snailmailed in, it's actually often resolved faster and is more likely 
  126.  to be accepted.  That's because you make sure that the printing's all 
  127.  nice and tidy and the figures are all there.  When an article is 
  128.  ZIPped and uuencoded and the figures are here and there and so forth, 
  129.  things can get messed up pretty easily.  Our snailmail address is:
  130.  
  131.     Game Developer magazine
  132.     600 Harrison St., Fourth Fl.
  133.     San Francisco, CA 94107
  134.     Atten.: Submissions
  135.  
  136.  Or, if you really feel strongly about it, you can e-mail a plain 
  137.  ASCII, WordPerfect 5.1, or Word for Windows file to 
  138.  larryo@well.sf.ca.us  Figures must be in TIFF or PCX format.
  139.  
  140. Article formatting
  141.  
  142.  We reformat all articles during the production phase, so you should 
  143.  not worry about page layout.  However, there are a few things you 
  144.  should know to give your articles a professional appearance.
  145.  
  146.  Use short paragraphs.
  147.  
  148.  Use only one level of subhead.  Although you may (and probably should) 
  149.  use more than one level of subhead for your own outline, when you turn 
  150.  this into an article you need to write transitions.
  151.  
  152.  You should only worry about three fonts: a body font, a subhead font, 
  153.  and a code font.  We use Caslon, Folio, and Voice Comp, respectively, 
  154.  but you don't have to worry about that.  Code font should be used for 
  155.  program code, variable names, program names, and object names.  If 
  156.  you're submitting an ASCII file and need to indicate code font, use  
  157.  <codefont> and <end> to tag the text.  Replace all tabs with four 
  158.  spaces.
  159.  
  160.  Code snippets of four lines or less can be put inline with the text.  
  161.  Anything longer needs to be broken out into listings. Our listings are 
  162.  either 40 or 80 characters wide.  Please format your code in a way 
  163.  that minimizes lines but maintains good style.  For instance, we 
  164.  prefer:
  165.  
  166. for(int i = 0; i < 10; i++){
  167.     doSomething(i);        //matrix transform
  168.     doSomethingElse(i);    //post process matrix
  169. }
  170.  
  171.  to either:
  172.  
  173. for(int i=0;i<10;i++){doSomething(i);doSomethingElse(i);}
  174.  
  175.  or:
  176.  
  177. for(int i = 0; i < 10; i++)
  178. {
  179. /* matrix transform */
  180. doSomething(i);
  181. /* post process matrix */
  182. doSomethingElse(i);
  183. }
  184.  
  185.  Listings and figures need to be referenced in the text.  You always 
  186.  have to use a phrase along the lines of "Because, as can be seen in 
  187.  Figure 3, the viewpoint has moved, we must transform the 
  188.  <codefont>Foo<end> matrix, as shown in Listing 1."
  189.  
  190.  The text must be more than a walkthrough of the code: "Then, we call 
  191.  <codefont>foo()<end>.  This returns an integer, 
  192.  <codefont>iRetVal<end>, which we pass to <codefont>bar()<end>."
  193.  
  194. Submit, Damn You!
  195.  
  196.  Game Developer was started as a guerrilla project by a bunch of 
  197.  editors at Miller Freeman Inc., the company that publishes such 
  198.  mainstream Software development magazines as Dr. Dobb's Journal, 
  199.  Software Development, and Microsoft Systems Journal.  We felt that a 
  200.  magazine devoted to game programming would be a hit with programmers, 
  201.  and we've had great success with our initial efforts.  But we want to 
  202.  get even more technical depth into the magazine, and we need your 
  203.  help.
  204.  
  205.  If you follow these guidelines, you'll have a great chance at being 
  206.  published in Game Developer and help make it into a magazine that's 
  207.  written by and for the best programmers in the world.
  208.  
  209.     Larry O'Brien (Editor-in-Chief)
  210.  
  211.     Game Developer magazine
  212.     600 Harrison St., Fourth Fl.
  213.     San Francisco, CA 94107
  214.  
  215.